perm filename LICKLI.LE4[LET,JMC] blob sn#147625 filedate 1975-02-21 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.require "let.pub" source
C00012 ENDMK
C⊗;
.require "let.pub" source;
∂AIL Dr. J.C.R. Licklider↓Director, Information Processing Techniques↓
Advanced Research Projects Agency↓1400 Wilson Blvd.↓Arlington, VA 20009∞
Dear Lick:

Your detailed comments on our proposal have greatly increased the probability
that you will get what you need, because they have greatly broadened the
interface between ARPA and the Stanford AI Lab.  This is because all the
group leaders now have a reasonably clear picture of what motivates ARPA
and the criteria we must meet in order to get ARPA support.  They all
value it highly, and one went so far as to say that it "restored his faith
in the government".

Here is what we plan to do to revise the proposal, and we hope to get the
revised version to you by March 6.

1. %2The introductory section will give a top down description of what AI
is and what problems it might solve in what time frame%1.  This will necessarily
contain much that has been previously said in other proposals and the AI
literature.
The introduction will be entirely comprehensible to a non-computer scientist
and almost entirely to a non-scientist.


2. %2A new top-down description of what we have accomplished up to the date
of the proposal%1.  We will make this as comprehensible as possible, but
the distinction between what we have just done and other things that have
been done will often be technical.

3. %2New versions, responsive to your comments, of the sections of the
proposal%1.  Technical matter will be relegated to appendices.  However,
I would feel very vulnerable if technical matter had to be omitted
completely, because our approaches to problems, our estimates of
what subproblems have to be solved, and the distinctions between what
we propose to do and what we or others have already done and what
others are doing cannot be supported completely non-technically.
I vaguely imagine that even if you don't use an outside technical review,
a Congressional staffer might or NAS might have to review AI or something.

Here are answers to some of your queries.  They will be incorporated in
the proposal, but I want to mention them now in case they are not adequate.

1. %2Why Pascal or Algol%1?

	The eventual practical use of verification techniques will require
programming languages designed with verification in mind.  Pascal, developed
by Niklaus Wirth in Zurich, is intended to be such a language, but because
of insufficient understanding, still doesn't quite make it, so no-one is
presently advocating that DoD switch to it.  The desire for a language
suitable for verification is compatible with all the virtues of present
languages and will be needed by the programmers in order to avoid complicating
their proofs by anomalies.  The IBM Vienna group used their %2Vienna
Definition Language%2 to make a formal definition of PL/I, but the
definition required many volumes because of anomalies that were merely
consequences of lack of understanding in the committees that developed
PL/I.  The even won the victory of getting IBM to declare their document
to be the %2official%1 definition of PL/I, but this victory was Pyhrric,
because, so far as I know, none of the implementers paid it any attention.
An attempt to reform the languages used for DoD computing to make verification
easy is premature at present, but will be required when the verifiers can
show that large programs can be verified.

2. %2What about the National Software Works?%1

	The only document we have on the National Software Works is eighteen
months old, so we don't know whether the things we are doing will fit in
with it.  I am quite certain that I wouldn't agree with everything they
(I don't even know exactly who?) would propose to do, but some of our
efforts might be adaptable to mesh.  However, to some extent I regard
the National Software Works as committee science, i.e. an effort by a
committee to agree on the solution to scientific problems.  Unfortunately,
the natural desire to come to an agreement often leads to wishful thinking
and the effort goes administratively well but the goal they have agreed
that their methods will achieve proves elusive.  We will be glad to have
one of our people, say Dave Luckham, participate in the planning, but
the authority of a committee won't necessarily convince me that they have
the right approach to program verification, language design, or some other
problem.  In my opinion, it is not in DoD's interest to try to
enforce a common approach to these problems; a single approach is too likely
to be wrong.  However, maybe if we new NSW better, we would like it and
I would like to be pointed to the documentation.

	The above is not entirely responsive to your questions, because
part of the question is when various of our efforts will be ready for
interaction with NSW, and we will try to be more specific about that.
However, it depends partly on whether NSW is a production or an
experimental organization, and it also depends on who its people are
and when they are ready to try a particular new technique.

3. %2Can't all mention of chess be suppressed?%1

	A. S. Kronrod, a Russian with similar problems, remarked that
Chess is the %2Drosophila%1 of artificial intelligence.  Elephants are
more useful than fruit flies, but you can't keep 1000 elephants in a
bottle on the shelf while you study their genetics.  Unfortunately
for this argument, most of the actual programs for playing chess that
have been developed have a sporting rather than a scientific motivation,
and not much is learned from their successes and failures.  The present
mention of chess is not at all in the context of making a program; it is
really to improve our capability of matching human reasoning.  The problem

	Let me try an analogy between a military intelligence problem
and the chess problem we have been using.